Authorization Code Grant
https://gyazo.com/b3653ab4355b08bc966c692631d25664
「自分の代わりに、他のサービスと連携してください」のような旨を伝える感じ
client目線では、userと認可サーバーがやり取りをして貰う必要がある
そのために、redirectするための情報を含めてresponse (302 Found)を返す responseには以下の情報を含んだurlを返す
認可サーバーのurl
response_type=code
scope="read write"
client_id=client-1
redirect_uri=<clientのURL>
state=XXX
⑨で使う
②によってredirectし、認可サーバーにrequestを送る
②でclientから受け取った権限の要求を行う
redirectなので、②でclientから受け取った情報もそのまま認可サーバーに送ることになる
response_type=code
scope="read write"
client_id=client-1
redirect_uri=<clientのURL>
state=XXX
④⑤ 認可サーバーはuserに認証させる
認証の方法は仕様では決まっていないので何でも良い
e.g. password、証明書、etc.
ここでは④と⑤にしているが、実際は何回かやりとりがあるかもしれない
ここの利点
clientがcredentialを知ることはない
ここの認証方法が代わっても、client/protected resourceの間に影響しない
⑥⑦ userは「clientを認可する」という旨を認証サーバーに伝える
どこまで権限を委譲するかを指定する
認証サーバーは、この指定を保存しておく
次回に同じような操作をする時に、⑥⑦のやりとりを省略できる
④⑤は省略できないが、⑥⑦は省略できる
Clientにrequestを送るようにredirectを返す
responseには以下の情報を含んだurlを返す
clientのurl
state=XXX
②や③と全く同じ値のもの。⑨で使う
⑨ userはClientにredirect
⑧で認証サーバーから受け取ったものをそのままClientに渡す
state=XXX
②で生成したstateの値と同じかどうかを確認するために使う
これでやっと、clientは認可コードを受け取ることができた POSTで以下のものを送信
Authorization headerで、client_idとclient_secretを付与
BASIC認証する
code=認可コード
grand_type=authorization_code
認可コードが初めて使われたものなのかなども検証
認可サーバーは③~⑧らへんで、userとClientの情報を紐付けて保存しているので検証することができる
access_token
token_type
⑫ clientはresourceにrequest
bearrer認証など
これが本来の目的
User目線でのページ遷移
①でアクセスすると④(formなどのあるページ)が返ってくる
passを入力して⑤を送信して、⑥(認証しますか？のようなページ)が返ってくる
「認証します」を⑦で送信
これで終わり
裏で⑧~⑫が行われる感じになる
User目線ではかなり簡潔
Authorization Code Grantに認証の仕組みを追加で実装する
https://youtu.be/PKPj_MmLq5E?t=2294